REMARKS 

The above amendment and these remarks are responsive to 
the non- final office action of Examiner Pham, mailed 18 Jan 
2005. 

Claims 1-15 are in the case, none as yet allowed. 

Record of Interview 

Applicants' attorney expresses appreciation to Examiner 
Pham for courtesy extended in an telephonic interview held 
on 24 March 2005. 

Prior to that interview, applicants provided to the 
Examiner a proposed amendment after final and an applicant 
initiated interview request form identifying for discussion 
(1) 112 rejection of claims 2 and 3, (2) 103 rejection of 
claims 1-3, 5-7, 12 and 14 over Meriwether in view of Clark, 
and (3) 103 rejection of claims 2, 8-11, 13, and 15 over 
Meriwether in view of Clark and Bolton. 

In the course of the interview, discussion items 2 and 
3 were addressed, including discussion of claims with 
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respect to Meriwether, Clark and Bolton. It was determined 
that, subject to an update search (which would require an 
RCE) , that the claims could be made "probably" allowable by 
including the following limitations: 

a. Operation at the Telnet (application) level; 

b. Confirmation record selected from the set of 
responses consisting of a success response and an 
error response, both including a response code and 
diagnostic information including device name; and 

c. Device name requested by client. 

All claims have been amended to include these 
limitations, variously stated (the Telnet limitation being 
described more generically in some of the claims by 
reference to a connection oriented client/server protocol. 
See, for example, claim 12) . 



35 U.S.C. 112 



Claims 2 and 3 have been rejected under 35 U.S.C. 112, 
second paragraph, for the use of the phrases "implicit 
request" and "explicit request", respectively. 
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"Implicit" means the Confirmation record is not 
directly requested via an environment variable. When is an 
"implicit" request ever seen? When we have a *printer* 
connection. A printer session *must* have a confirmation 
record to proceed (the specification refers to the printer 
confirmation record as the "default" confirmation record) . 
Since applicants' invention is directed to *display* 
confirmation records (which the patent refers to as "custom" 
confirmation records, because we can optionally add extra 
data onto the end of the default record) , there is a bit of 
a distinction, which applicants refer to as "implicit" and 
"explicit" requests for confirmation records. This is 
described on page 12, lines 9-12. 

In any case, for displays, the record must be 
"explicitly" requested, since while it f s required for 
printers it is not required for displays. 

However, to avoid misunderstanding on terms 
"explicitly" and "implicitly", applicants have amended 
claims 2 and 3 to more closely track the disclosure in 
applicants' specification, which states: 

"In step 58, server 42 instructs client 40 to send 
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several parameters, and in step 60 client 40 responds. 
In accordance with the preferred embodiment of the 
invention, in the response of step 60, client 40 
requests with the code "USERVAR x IBMSENDCONFREC ' VALUE 
X YES'" that server 42 send a confirmation record 100. 
Alternatively, such a request may be implied from some 
other parameter in connection with the new environment 
negotiations. Thus, for example, client 40 may have to 
specifically request a confirmation record 100 when 
requesting connection of a virtual display device , but 
such would be implied when requesting connection of a 
virtual printer device ." [Specification, page 12. 
Emphasis added.] 



With this understanding, applicants request that the 
rejection of claims 2 and 3 under 35 U.S.C. 112 be 
reconsidered and withdrawn. 

35 U.S.C. 103 

Claims 1-3, 5-7, 12, and 14 have been rejected under 35 
U.S.C. 103(a) over U.S. Patent 5,931,913 (Meriwether) in 
view of U.S. Patent 6,304,905 (Clark). 



With respect to claims 1, 12, and 14, the Examiner 
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discusses the Meriwether and Clark references as follows: 

Meriwether teaches operating a client to establish a 
network connection with a server, comprising: 
negotiating environment parameters for establishing a 
connection-oriented connection with said server (col. 7 
lines 40-44, "a communication channel is established 
...to established a session"); said parameters 
including a request for said server to provide a 
confirmation/status record (col. 3 lines 46-49, 
"Establishment of the communications . . . the 
communications channel") ; and responsive to said 
request, receiving said confirmation/status record 
(col. 7 lines 47-52, "The request may be communicated 
...to the client 214"). Meriwether , does not teach the 
confirmation record containing descriptive information 
about a connection which is held for the duration of a 
file transfer or dialog. However, Clark teaches 
connection between clients and a server via a telnet 
session in which the client issues a request to a sever 
and the server must response back with a mandatory 
descriptive information about the connection (col. 7 
lines 1-11, "a first network node issues ... to the 
client promptly or immediately") for the purpose of 
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inquiring whether the server is on-line and accepting 
the negotiation with the client... . (OCR version of 
Office Action. ) 

Applicants have amended claims 1, 12, and 14. 

Nowhere does Meriwether or Clark teach a 
confirmation/status record as applicants' have defined it 
(with a device name, a status code, optional exit 
programming, etc., using modern language -- however the - 
claims are amended using equivalent language from the 
specification) . 

Meriwether talks about a confirmation, but there is no 
description of it anywhere. In Meriwether's case, a 
confirmation record is probably "1" for success and a "0" 
for failure. 

Clark nowhere shows a confirmation record with a device 
name, status, exit program information (response code), etc. 
included. At best, Clark uses the current set of Telnet 
protocol options, which does not have applicants' 
Confirmation Record defined. 
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Furthermore, Clark is specifically looking to see a 
negative response from the server to identify the existence 
of the server, and not to receive any information (beyond 
the fact of any response at all) in the response upon which 
it can act. In fact, Clarks' patent design allows him to 
use any Telnet protocol option he desires, whether it 
actually exists or not (preferably not, because using a real 
one will confuse the server) , send "that" to the server and 
hopefully get a (negative) response from the server (if one 
exists) . There is nothing descriptive in the server 
response - it amounts to an expected "no, I won't do this" 
type negative response. Thus, Clark is simply looking for 
any response at all, and making decisions based upon the 
existence of one. 

Going back to Meriwether, the confirmation that 
Meriwether is seeing is most likely of the "success" or 
"failure" return code variety. If the "communications 
channel connection" to the remote host is successful, it 
means he can begin talking to that host using the Telnet 
protocol. Thus the "communications channel" (which is 
likely "TCP/IP sockets" in this case, see col. 3 lines 55- 
60) allows the "computer readable program code" (which is 
"Telnet" in this case, see col. 3, lines 60-65) to 
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communicate over it. The "communications channel" in this 
case is clearly not the Telnet protocol as defined in the 
art, because the Telnet protocol is "communicating . . . via 
the communications channel" (Examiner's citation). 

Applicants "confirmation record" (also referred to in 
the specification as a "response record") is not 
"confirmation" in the sense that Meriwether is using it. 
Applicant's use of the term is as the name of a piece of 
information the server returns to the client once the Telnet 
protocol negotiations are finished. This "confirmation 
record" is a success or failure response record containing 
descriptive information about the Telnet session itself. 

On the other hand, Meriwether uses the term 
"confirmation" in the sense that the session connection was 
established - that the client was able to connect to the 
server so that it can start the Telnet protocol 
negotiations. Thus, Meriwether's description is not 
referring to "Telnet protocol communications" (in the 
context of "confirmation") but rather to "TCP/IP protocol 
communications" . 

Applicant's claims 1, 12, and 14 are here referring to 
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"environment parameters" which are Telnet or the like 
protocol parameters. Meriwether is describing a general 
communications connection between a client and server, 
normally something supplied via sockets in the layer below 
Telnet, which creates a connection over which the Telnet 
protocol information can then be sent. This can be seen in 
Col. 7, lines 50-55 where Meriwether states that after the 
"...confirmation of establishment of the channel... " that a 
"...Telnet dialog can then commence...". In other words, no 
Telnet environment parameter negotiation has yet begun when 
Meriwether's "confirmation" is issued, which is only an 
indication that a communications channel has been 
established (but no Telnet dialog has yet occurred.) 

Here, applicants are using the word Telnet in the sense 
set forth in their specification at page 19, lines 3-17 to 
include applications where according to protocols that make 
use of a confirmation record confirming attributes 
associated with an actual persistent connection. An example 
of such a protocol is the file transfer protocol (FTP) , in 
which a connection is initiated and held for the duration of 
a file transfer . Telnet initiates and holds the connection 
for the duration of the dialogue between the attaching 
client emulator that initiates the connection to a targeted 
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host server and its application. 

Claims 2, 3 and 5-7 depend from claim 1, and are 
similarly distinguished. 

Further with respect to claims 2 and 3, applicants have 
amended the claims to conform to the specification. 
Applicants note that Meriwether does not actually define 
'explicit' or 'implicit' either. One of skill in the art 
would interpret the 'explicit' and 'implicit' that 
Meriwether is talking about as referring to Telnet 
protocols, which do not define a confirmation record (as 
that term is defined by applications in the amended base 
claim 1 . ) 

Regarding claim 5, the Examiner states: 

"Clark teaches the confirmation record including a 
response code indicative of the cause of a failed 
connection (col. 7 lines 5-7, "The responsive message 
may be ... a confirmation, or the like."). 

Claim 5 depends from base claim 1, and is distinguished 
as previously described. 
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Further, in Clark, the response can be anything because 
he doesn't care what it is, only if it is. There is no 
intelligence exploiting the existing protocol response. For 
Clark, he could receive any protocol response and 
authoritatively declare "the server is online" , but what 
good is that information to someone who's unable to use the 
server? Knowing the server is online doesn't help us know 
why someone cannot use that server (that knowing that a 
server is "offline" does not constitute intelligence here) . 
Thus, Clark has not taught an intelligent "confirmation" as 
applicants have defined confirmation record in the amended 
base claim 1. Clark is simply using existing protocols (he 
has defined nothing new) and trying to infer some status and 
perform some recovery based on these protocol responses . 

Regarding claim 6, the Examiner states: 

"Meriwether responsive to said response code, retrying 
said negotiating step (col 8 lines 55-63, "Those skill 
in the art., establishment messages illustrated"). 

Applicants traverse. Applicants' retry is based upon 
the status found in the Confirmation record, not based upon 
existing Telnet protocols. Thus, applicants' attempt to 
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"retry" the negotiation of (for example) the user password 
because the password is invalid is not possible under 
Meriwether. Meriwether has no provisions for anything 
outside standard Telnet protocols, and his retry blocks 
simply show the existing Telnet protocols. 

Regarding claim 7, the Examiner states: 

Meriwether teaches client being a Telnet client, and 
said negotiating step including negotiating new 
environment and terminal type parameters (col. 4 lines 
3-31, "a session may be ... the second number of 
transfers" ) . 

Applicants have amended claim 7 to clarify that the 
negotiating step includes negotiating new environment and 
confirmation record parameters..." thus more clearly 
distinguishing the claim from a normal Telnet client (and 
Meriwether) . 

Claims 4, 8-11, 13 and 15 have been rejected under 35 
U.S.C. 103(a) over Meriwether in view of Clark and further 
in view of U.S. Patent 6,128,662 (Bolton). 
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Regarding claim 4 (which depends from base claim 1) , 
the Examiner states : 

Meriwether and Clark teach operating a client to 
establish a network connection with a server providing 
a confirmation record but does not teach a device name 
assigned by the server to the client connection. 
However, Bolton teaches a virtual name is generated by 
the server to the client during negotiation (col. 7 
lines 50-56, "we generate the model string ... the 
device type as the key") for the purpose of eliminating 
the need of the server to maintain a table of different 
devices. Therefore, it would have been obvious to one 
of ordinary skill in the art at the time of the 
invention to incorporate the virtual device name of 
Bolton with the systems of Meriwether and Clark because 
it would provide for the purpose of eliminating the 
need of a server to maintain a table of different 
devices . 

As discussed above with respect to base claim 1, 
Meriwether and Clark do not teach Confirmation Records as 
now defined in currently amended claim 1. 
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In addition, applicants' invention allows the device 
name to be requested specifically by the client, rather than 
"assigned" by the server. Applicants' Figure 3 block 60 
shows requesting a device by name (called "MYDEVICE" ) and is 
a separate step from the terminal type negotiation, which is 
step 64, which is further described at page 15, lines 1-12 
(below Table 5) , of their specification. . 

Thus, applicants' invention allows any terminal type 
that is negotiated to be assigned a device name of the 
clients choosing (which is not possible under Bolton - the 
device name is built from the terminal type negotiated) . In 
Bolton's case, the device assigned will be something like 
"317902" per Bolton Figure 6 block 34. As the Examiner 
states, the device name is built from the terminal type 
negotiations . 

Regarding claims 8, 9, 13, and 15, the Examiner states: 

Meriwether teaches operating a server in a network, 
comprising the steps of receiving a connection request 
from a client (coL 3 lines 46-49, "Establishment of the 
communications... the communications channel"); 
inviting said client to negotiate environment 
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parameters (col. 7 lines 54-62, "a Telnet logon dialog 
... binary transmission option negotiation"); 
responsive to client acceptance, negotiating said 
parameters (col. 7 line 65 to col. 8 line 4, "terminal 
type information received ... and the server 23 2 M ); 
responsive to receiving a request for a confirmation 
record, providing to said client a confirmation record 
(col. 7 lines 47-5 2, "The request may be communicated 
... to the client 214")... 

Applicants traverse. Meriwether does not teach 
applicants' Confirmation Record, which contains descriptive 
information about a connection which is held for the 
duration of a file transfer or dialog including, for a 
successful connection, said virtual device name and, for an 
unsuccessful connection, a return code indicative of the 
cause of failure of said connection. 

The Examiner continues: 

Meriwether does not teach assigning a virtual device 
name to said client; and the confirmation record 
containing descriptive information about a connection 
which is held for the duration of a file transfer or 
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dialog including, for a successful connection, said 
virtual device name and, for an unsuccessful 
connection, a return code indicative of the cause of 
failure of said connection. However, Clark teaches 
connection between clients and a server via a telnet 
session in which the client issues a request to a sever 
and the server must response back with a mandatory 
descriptive information about the connection (coL 7 
lines 1-11, "a first network node issues... to the 
client promptly or immediately") for the purpose of 
inquiring whether the server is on-line and accepting 
the negotiation with the client. 

Applicants traverse. In Clark, the response can be 
anything because he doesn't care what it is, only if it is. 
There is no intelligence exploiting the existing protocol 
response. For Clark, he could receive any protocol response 
and authoritatively declare "the server is online". 
However, merely knowing the server is online doesn't help a 
client know why it cannot use that server (that knowing that 
a server is "offline" does not constitute intelligence 
here) . Thus, Clark has not taught an intelligent 
"confirmation" as applicants have defined confirmation 
record in claim 8 as including descriptive information about 
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a connection which is held for the duration of a file 
transfer or dialog including, for a successful connection, 
the virtual device name and, for an unsuccessful connection, 
a return code indicative of the cause of failure of the 
connection, Clark is simply using existing protocols and 
trying to infer some status and perform some recovery based 
on these protocol responses . 

The Examiner continues: 

"Therefore, it would have been obvious to one of 
ordinary skill in the art at the time of the invention 
to incorporate the request/response negotiation of 
Clark with Meriwether because it would provide for the 
purpose of inquiring whether the server is on-line and 
accepting the negotiation with the client..." 

Applicants traverse. Merely knowing that the server is 
on-line and accepting negotiation with the client is 
insufficient. Applicants confirmation record (aka response 
record) includes response codes with descriptive information 
about a connection which is held for the duration of a file 
transfer or dialog including, for a successful connection, 
the virtual device name and, for an unsuccessful connection, 
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a return code indicative of the cause of failure of the 
connection. 

The Examiner continues: 

"Furthermore, Bolton teaches a virtual name is 
generated by the server . . . " 

Applicants have amended the claims to clarify that the 
virtual name assigned is one requested by the client, and 
thus do what Bolton cannot. 

The Examiner continues: 

"to the client during negotiation (col. 7 lines 50-56, 
"we generate the model string . . . the device type as 
the key") for the purpose of eliminating the need of 
the server to maintain a table of different devices. 
Therefore, it would have been obvious to one of 
ordinary skill in the art at the time of the invention 
to incorporate the virtual device name of Bolton with 
the system of Meriwether because it would provide for 
the purpose of eliminating the need of a server to 
maintain a table of different devices. 
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In applicants invention there is no need to eliminate a 
table of devices at the server. Applicants' motivation is 
to provide for intelligent correction of negotiations based 
upon actual errors received from the server. 

Regarding claims 10 and 11, these depend from base 
claim 9. Unlike Meriwether, applicants' Telnet client 
supports a custom confirmation record as discussed 
previously with respect to claim 9. Further, implicit and 
explicit requests for confirmation records occur for 
printers (implicit) and displays (explicit) . Meriwether is 
simply describing Telnet protocols, which allow for the 
server to indicate the session is complete and ready in an 
implicit (no more negotiations are seen) or explicit (actual 
transaction data now flows) manner. 



SUMMARY AND CONCLUSION 

Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-15. 



The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
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differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707.02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
necessary. 



Date: 24 March 2005 

Shelley M Beckstrand, P.C. 
Patent Attorney 
61 Glenmont Road 
Woodlawn, VA 24381 

Phone: (276) 238-1972 

Fax: (276) 238-1545 
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Sincerely, 



R. G. Hartmann, et al . 



By 




